Loading...
 

Dedicated ClassiX instances

Dedicated ClassiX instances

4.1.0
204939

Dedicated ClassiX instances are a MorphIT feature which offers additional flexibility for large MorphIT installations (example: ClassiX Cloud).

Problem definition

The basic concept of a distributed MorphIT installation is that there is a MorphIT server where the HTTP requests are received, where all ClassiX instances and all MorphIT launchers register. The MorphIT server starts an adjustable number of ClassiX instances in stock, so that the user does not experience any delay after the static login when connecting to a ClassiX instance. For load distribution, MorphIT-Launcher can be set up distributed on several machines and the server will try to start the ClassiX instances in a way that the MorphIT-Launcher are loaded as evenly as possible.

The consequence of this is that even before the first user interaction it must be known how a ClassiX instance is jammed. This means, that a user normally cannot run several different MorphIT applications on one MorphIT server, because the client cannot (and for security reasons must not!) tell the server, which ClassiX application should be started.

Simple solution

The simplest solution to this problem is to duplicate the MorphIT infrastructure. In concrete terms this means

  1. For each MorphIT application, a MorphIT server and (several) MorphIT Launcher(s) are set up, running on a different port or machine than the first application
  2. A proxy is connected in front of the MorphIT servers, which forwards the requests to the corresponding server based on the URL.

However, this simple solution only lends itself to a small and unchanging number of MorphIT applications, because setting up a new application involves considerable effort, as the infrastructure must be set up and configured.

Dedicated ClassiX instances

The more flexible solution to this problem is the dedicated ClassiX instances. A ClassiX instance can log on to the MorphIT server at runtime to start a new ClassiX instance. As soon as a ClassiX instance is connected to a MorphIT server(HasMorphITConnection = TRUE), it can use RequestMorphITBinding to register the start of a new ClassiX instance with the server and LaunchDedicatedClassiX to start this instance from any MorphIT launcher. For this purpose the MorphIT server generates a tuple of web socket ID and launcher nonce, via which the server ensures that the started ClassiX instance is only connected to the corresponding MorphIT client (in a new tab).

A detailed description how the coupling between ClassiX and MorphIT client works and what has to be considered can be found here.

Simple start of a dedicated ClassiX instance
Simple start of a dedicated ClassiX instance
Starting a dedicated ClassiX instance via the static web service and the MorphIT launcher
Starting a dedicated ClassiX instance via the static web service and the MorphIT launcher

Launcher configuration

To control more precisely which ClassiX instances are executed where, the MorphIT Launcher can be configured to be used exclusively for dedicated ClassiX instances. This way you do not have to configure the system on every machine where a Launcher is running, so that the regular MorphIT application can be started there, and you can set up a different ClassiX application on every machine. If the key ws.launcher.launch.cmd is not set in the configuration of a MorphIT launcher, a warning message is displayed when the launcher is started and the launcher is not used by the server to start regular ClassiX instances. Such a launcher is marked accordingly in the admin console.

The restriction in the number of startable instances(ws.launcher.max_instances) also applies to the dedicated ClassiX instances. If the limit is reached, LaunchDedicatedClassiX will fail and no further instance will start on this launcher.

Server configuration

No additional configuration of the server is necessary for the start of dedicated instances. Since the start of these dedicated instances is initiated by a ClassiX instance, this also works if the launch strategy is deactivated in the server(launch_strategy.enabled=false).